Skip to content

fix(changes): actionable error when settings exist but *_cloudsync tables are missing#55

Merged
andinux merged 1 commit into
mainfrom
fix/changes-vtab-nomem-misclassification
Jul 14, 2026
Merged

fix(changes): actionable error when settings exist but *_cloudsync tables are missing#55
andinux merged 1 commit into
mainfrom
fix/changes-vtab-nomem-misclassification

Conversation

@andinux

@andinux andinux commented Jul 14, 2026

Copy link
Copy Markdown
Collaborator

Problem

Querying cloudsync_changes (directly or via cloudsync_payload_blob_checked()) on a database whose cloudsync_table_settings rows survived while every *_cloudsync meta table was lost — e.g. a dump/restore that skipped them — returned SQLITE_NOMEM: the NULL from vtab_build_changes_sql fell through the config-exists guard added in #54. SQLite Cloud reported it on the /check path as 10000 Not enough memory to execute query, pointing operators at memory instead of the real state (observed in production while diagnosing a customer node).

Fix

cloudsync_changesvtab_filter now distinguishes the state: settings rows present but zero %_cloudsync tables in sqlite_master raises

cloudsync settings reference tables whose sync metadata is missing (no *_cloudsync tables found). Re-run SELECT cloudsync_init('<table_name>') for each configured table to rebuild it.

Genuine OOM (at least one meta table exists) still returns SQLITE_NOMEM.

Testing

  • New unit test Changes Vtab Missing Meta Tables: init a table, drop its meta table, assert SQLITE_ERROR with the actionable message. Red before the fix, green after.
  • Full SQLite suite: 148/148 OK.
  • Verified end-to-end via CLI on a repro database: the query now returns the actionable message instead of out of memory (7).

SQLite vtab only — no PostgreSQL changes, extension version stays 1.1. Bumps CLOUDSYNC_VERSION to 1.1.2 with CHANGELOG entry.

🤖 Generated with Claude Code

…bles are missing

Querying cloudsync_changes on a database whose cloudsync_table_settings
rows survived while every *_cloudsync meta table was lost (e.g. a
dump/restore that skipped them) returned SQLITE_NOMEM: the NULL from
vtab_build_changes_sql fell through the config-exists guard and was
reported by SQLite Cloud as "Not enough memory to execute query" on the
/check path, pointing operators at memory instead of the real state.

- xFilter now distinguishes this state (settings rows present, zero
  %_cloudsync tables in sqlite_master) and raises "cloudsync settings
  reference tables whose sync metadata is missing" with the re-init
  remediation; genuine OOM still returns SQLITE_NOMEM
- unit test: Changes Vtab Missing Meta Tables (red before, green after)
- bump CLOUDSYNC_VERSION to 1.1.2 and add the CHANGELOG entry (SQLite
  vtab only, no PG changes, extension version stays 1.1)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@andinux andinux merged commit c600156 into main Jul 14, 2026
60 of 61 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant